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DETAILED ACTION 
Continued Examination Under 37 CFR 1.114 

1. A request for continued examination under 37 CFR 1.1 14, including the fee set forth in 
37 CFR 1.17(e), was filed in this application after final rejection. Since this application is 
eligible for continued examination under 37 CFR 1.1 14, and the fee set forth in 37 CFR 1.17(e) 
has been timely paid, the finality of the previous Office action has been withdrawn pursuant to 
37 CFR 1.114. Applicant's submission filed on December 05, 2005 has been entered. 

Claim Objections 

2. Claims 4-5, 16-17, 28 and 29 are objected to because of the following informalities: 
Cancelled claims must be indicated as "Canceled" and the text of the claims must not be 
presented. Please see 37 CFR 1.121 for additional information. Appropriate correction is 
required. 

Claim Rejections - 35 USC § 102 
The following is a quotation of the appropriate paragraphs of 35 U.S.C. 102 that form the 
basis for the rejections under this section made in this Office action: 
A person shall be entitled to a patent unless - 

(e) the invention was described in (1) an application for patent, published under section 
122(b), by another filed in the United States before the invention by the applicant for 
patent or (2) a patent granted on an application for patent by another filed in the United 
States before the invention by the applicant for patent, except that an international 
application filed under the treaty defined in section 351(a) shall have the effects for 
purposes of this subsection of an application filed in the United States only if the 
international application designated the United States and was published under Article 
21(2) of such treaty in the English language. 

3. Claims 1, 6-7, 9-10, 13, 18-19, 21-22, 25, 30-31, 33 and 34 are rejected under 35 
U.S.C. 102(e) as being anticipated by Brendel (US Patent No. 6,772,333B1). 
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With respect to claim 1, Brendel discloses a method comprising: 

receiving a data packet from a source (col. 9, lines 3-4, the load-balancer reads incoming 
packets); 

determining whether a session identity exists for a communication session with the 
source (col. 9, lines 5-7, the load-balancer will attempt to find the SSL session entry for SSL 
session ID in its SSL session table using SSL ID field 90); 

encapsulating the received data packet in a flow header including at least two of a flow 
message type field, a flow option field, a source port identity field, a destination identity field, 
and a session identity field in the header of the received data packet and transmitting the flow 
header with the received data packet to a destination if no session identity exists (col. 10, lines 5- 
13, when no matching SSL session ID is found in the table, the connection is for a new SSL 
session. The server is then assigned using the default load-balancing method, whether random, 
least used, or some other assignment method. The server-generated SSL session ID, which is 
then returned from the server in the same connection as part of the response to the encrypted 
client request, is stored in a new or empty entry in the table, along with the server the connection 
was assigned to. This implies that the client request is encapsulated and forwarded to the 
assigned server by the load-balancer. Herein, the addresses of the connection contains the 
destination address of the assigned server, e.g., MAC or IP address, col. 9, lines 10-12, and the 
source address and port, e.g., address and port of the load-balancer since the load-balancer 
connects to a plurality of servers. Therefore, the forwarded packet including at least two of 
source port identity field and destination identity field); 
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receiving the session identity from the destination using the flow header (col. 10, lines 9- 
13, the server-generated SSL session ID, which is then returned from the server in the same 
connection as part of the response to the encrypted client request, is stored in a new or empty 
entry in the table, along with the server the connection was assigned to. Herein, the addresses of 
the connection are the address of the server and address and port of the balancer); and 

transmitting subsequent data packets received from the source along with the session 
identity to the destination (col. 10, lines 15-18, subsequent connections having the same SSL 
session ID will be directed to the same server, ensuring that all connections for the encrypted 
session are processed by the same server). 

With respect to claims 6-7, 18-19, 30 and 31, Brendel discloses removing a header prior 
to transmitting data packets received from the destination to the source; using information in the 
header to transmit data packets received from the destination to the source; and wherein the 
information in the header comprises the source port identity (col. 8, lines 21-26, the new entry 
contains the SSL session ID, and the IP address of the server. The load-balancer associates the 
SSL session ID with the server that generated the SSL session ID, server X. The client also 
stores the SSL session ID and uses for all encrypted connections with the server. Herein, the 
destination address in the header of the packets, e.g., load-balancer's address, is removed and 
replaced with the address of the client, e.g., client IP address and port). 

With respect to claim 9, Brendel discloses a method comprising: 
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receiving a data packet from a source through a network node (col. 10, lines 5-13, when 
no matching SSL session ID is found in the table, the connection is for a new SSL session. The 
server is then assigned using the default load-balancing method, whether random, least used, or 
some other assignment method. Herein, the server receives the packet through the load- 
balancer); 

determining whether a session identity exists for a communication session with the 
source (col. 9, lines 5-7, the load-balancer will attempt to find the SSL session entry for SSL 
session ED in its SSL session table using SSL ID field 90); 

encapsulating the received data packet in a flow header including at least two of a flow 
message type field, a flow option field, a source port identity field, a destination identity field, 
and a session identity field in the header of the received data packet and generating a session 
identity if no session identity exists (col. 10, lines 5-13, when no matching SSL session ID is 
found in the table, the connection is for a new SSL session. The server is then assigned using the 
default load-balancing method, whether random, least used, or some other assignment method. 
The server-generated SSL session ID, which is then returned from the server in the same 
connection as part of the response to the encrypted client request, is stored in a new or empty 
entry in the table, along with the server the connection was assigned to. This implies that the 
client request is encapsulated and forwarded to the assigned server by the load-balancer. Herein, 
the addresses of the connection contains the destination address of the assigned server, e.g., 
MAC or IP address, col. 9, lines 10-12, and the source address and port, e.g., address and port of 
the load-balancer since the load-balancer connects to a plurality of servers. Therefore, the 
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forwarded packet including at least two of source port identity field and destination identity 
field); and 

transmitting the session identity to the network node (col. 10, lines 5-13, the server- 
generated SSL session ID, which is then returned from the server in the same connection as part 
of the response to the encrypted client request, is stored in a new or empty entry in the table of 
the load-balancer, along with the server the connection was assigned to). 

With respect to claims 10, 22, and 34, Brendel discloses obtaining session identity from 
the data packet if one is included in the data packet (col. 9, lines 3-5, the load-balancer reads 
incoming packets and extracts SSL session ED for encrypted sessions); obtaining address 
information of the network node and transmitting data to the network node using address 
information (col. 10, lines 5-13, the server-generated SSL session ID, which is then returned 
from the server in the same connection as part of the response to the encrypted client request, is 
stored in a new or empty entry in the table of the load-balancer, along with the server the 
connection was assigned to. Herein, the destination address is the address of the load-balancer). 

With respect to claim 13, Brendel discloses an article of manufacture comprising: 
machine-readable medium including instructions that when executed by a machine, 

causes the machine to perform operations (Fig. 9, client, load-balancer, and server must include 

medium for storing executed instructions) comprising: 

receiving a data packet from a source (col. 9, lines 3-4, the load-balancer reads incoming 

packets); 
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determining whether a session identity exists for a communication session with the 
source (col. 9, lines 5-7, the load-balancer will attempt to find the SSL session entry for SSL 
session ID in its SSL session table using SSL ID field 90); 

encapsulating the received data packet in a flow header including at least two of a flow 
message type field, a flow option field, a source port identity field, a destination identity field, 
and a session identity field in the header of the received data packet and transmitting the flow 
header with the received data packet to a destination if no session identity exists (col. 10, lines 5- 
13, when no matching SSL session ID is found in the table, the connection is for a new SSL 
session. The server is then assigned using the default load-balancing method, whether random, 
least used, or some other assignment method. The server-generated SSL session ID, which is 
then returned from the server in the same connection as part of the response to the encrypted 
client request, is stored in a new or empty entry in the table, along with the server the connection 
was assigned to. This implies that the client request is encapsulated and forwarded to the 
assigned server by the load-balancer. Herein, the addresses of the connection contains the 
destination address of the assigned server, e.g., MAC or IP address, col. 9, lines 10-12, and the 
source address and port, e.g., address and port of the load-balancer since the load-balancer 
connects to a plurality of servers. Therefore, the forwarded packet including at least two of 
source port identity field and destination identity field); 

receiving the session identity from the destination using the flow header (col. 10, lines 9- 
13, the server-generated SSL session ID, which is then returned from the server in the same 
connection as part of the response to the encrypted client request, is stored in a new or empty 
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entry in the table, along with the server the connection was assigned to. Herein, the addresses of 
the connection are the address of the server and address and port of the balancer); and 

transmitting subsequent data packets received from the source along with the session 
identity to the destination (col 10, lines 15-18, subsequent connections having the same SSL 
session ID will be directed to the same server, ensuring that all connections for the encrypted 
session are processed by the same server). 

With respect to claim 21, Brendel discloses an article of manufacture comprising: 
a machine-readable medium including instructions that when executed by a machine, 
causes the machine to perform operations (Fig. 9, client, load-balancer, and server must include 
medium for storing executed instructions) comprising: 

receiving a data packet from a source through a network node (col. 10, lines 5-13, when 
no matching SSL session ID is found in the table, the connection is for a new SSL session. The 
server is then assigned using the default load-balancing method, whether random, least used, or 
some other assignment method. Herein, the server receives the packet through the load- 
balancer); 

determining whether a session identity exists for a communication session with the 
source (col. 9, lines 5-7, the load-balancer will attempt to find the SSL session entry for SSL 
session ID in its SSL session table using SSL ID field 90); 

encapsulating the received data packet in a flow header including at least two of a flow 
message type field, a flow option field, a source port identity field, a destination identity field, 
and a session identity field in the header of the received data packet and generating a session 
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identity if no session identity exists (col. 10, lines 5-13, when no matching SSL session ID is 
found in the table, the connection is for a new SSL session. The server is then assigned using the 
default load-balancing method, whether random, least used, or some other assignment method. 
The server-generated SSL session ID, which is then returned from the server in the same 
connection as part of the response to the encrypted client request, is stored in a new or empty 
entry in the table, along with the server the connection was assigned to. This implies that the 
client request is encapsulated and forwarded to the assigned server by the load-balancer. Herein, 
the addresses of the connection contains the destination address of the assigned server, e.g., 
MAC or IP address, col. 9, lines 10-12, and the source address and port, e.g., address and port of 
the load-balancer since the load-balancer connects to a plurality of servers. Therefore, the 
forwarded packet including at least two of source port identity field and destination identity 
field); and 

transmitting the session identity to the network node (col. 10, lines 5-13, the server- 
generated SSL session ID, which is then returned from the server in the same connection as part 
of the response to the encrypted client request, is stored in a new or empty entry in the table of 
the load-balancer, along with the server the connection was assigned to). 

With respect to claim 25, Brendel discloses a computer system comprising: 

a bus (Fig. 8, medium for connecting the session ID table 81 and receiving interface 82); 

a data storage device coupled to said bus (Fig. 8, table 81); and 
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a processor coupled to said data storage device (Fig. 8, assigned processor 85), 
said processor operable to receive instructions which, when executed by the processor, cause the 
processor to perform a method comprising: 

receiving a data packet from a source (col. 9, lines 3-4, the load-balancer reads incoming 
packets); 

determining whether a session identity exists for a communication session with the 
source (col 9, lines 5-7, the load-balancer will attempt to find the SSL session entry for SSL 
session ID in its SSL session table using SSL ED field 90); 

encapsulating the received data packet in a flow header including at least two of a flow 
message type field, a flow option field, a source port identity field, a destination identity field, 
and a session identity field in the header of the received data packet and transmitting the flow 
header with the received data packet to a destination if no session identity exists (col. 10, lines 5- 
13, when no matching SSL session ID is found in the table, the connection is for a new SSL 
session. The server is then assigned using the default load-balancing method, whether random, 
least used, or some other assignment method. The server-generated SSL session ID, which is 
then returned from the server in the same connection as part of the response to the encrypted 
client request, is stored in a new or empty entry in the table, along with the server the connection 
was assigned to. This implies that the client request is encapsulated and forwarded to the 
assigned server by the load-balancer. Herein, the addresses of the connection contains the 
destination address of the assigned server, e.g., MAC or IP address, col. 9, lines 10-12, and the 
source address and port, e.g., address and port of the load-balancer since the load-balancer 
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connects to a plurality of servers. Therefore, the forwarded packet including at least two of 
source port identity field and destination identity field); 

receiving the session identity from the destination using the flow header (col. 10, lines 9- 
13, the server-generated SSL session ID, which is then returned from the server in the same 
connection as part of the response to the encrypted client request, is stored in a new or empty 
entry in the table, along with the server the connection was assigned to. Herein, the addresses of 
the connection are the address of the server and address and port of the balancer); and 

transmitting subsequent data packets received from the source along with the session 
identity to the destination (col. 10, lines 15-18, subsequent connections having the same SSL 
session ID will be directed to the same server, ensuring that all connections for the encrypted 
session are processed by the same server). 

With respect to claim 33, Brendel discloses a computer system comprising: 

a bus (Fig. 8, medium for connecting the session ID table 81 and receiving interface 82); 

a data storage device coupled to said bus (Fig. 8, table 81); and 

a processor coupled to said data storage device (Fig. 8, assigned processor 85), 
said processor operable to receive instructions which, when executed by the processor, cause the 
processor to perform a method comprising: 

receiving a data packet from a source through a network node (col. 10, lines 5-13, when 
no matching SSL session ID is found in the table, the connection is for a new SSL session. The 
server is then assigned using the default load-balancing method, whether random, least used, or 
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some other assignment method. Herein, the server receives the packet through the load- 
balancer); 

determining whether a session identity exists for a communication session with the 
source (col. 9, lines 5-7, the load-balancer will attempt to find the SSL session entry for SSL 
session ID in its SSL session table using SSL ID field 90); 

encapsulating the received data packet in a flow header including at least two of a flow 
message type field, a flow option field, a source port identity field, a destination identity field, 
and a session identity field in the header of the received data packet and generating a session 
identity if no session identity exists (col. 10, lines 5-13, when no matching SSL session ID is 
found in the table, the connection is for a new SSL session. The server is then assigned using the 
default load-balancing method, whether random, least used, or some other assignment method. 
The server-generated SSL session ID, which is then returned from the server in the same 
connection as part of the response to the encrypted client request, is stored in a new or empty 
entry in the table, along with the server the connection was assigned to. This implies that the 
client request is encapsulated and forwarded to the assigned server by the load-balancer. Herein, 
the addresses of the connection contains the destination address of the assigned server, e.g., 
MAC or IP address, col. 9, lines 10-12, and the source address and port, e.g., address and port of 
the load-balancer since the load-balancer connects to a plurality of servers. Therefore, the 
forwarded packet including at least two of source port identity field and destination identity 
field); and 

transmitting the session identity to the network node (col. 10, lines 5-13, the server- 
generated SSL session ID, which is then returned from the server in the same connection as part 
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of the response to the encrypted client request, is stored in a new or empty entry in the table of 
the load-balancer, along with the server the connection was assigned to). 

Claim Rejections - 35 USC § 103 

The following is a quotation of 35 U.S.C. 103(a) which forms the basis for all 

obviousness rejections set forth in this Office action: 

(a) A patent may not be obtained though the invention is not identically disclosed or 
described as set forth in section 102 of this title, if the differences between the subject 
matter sought to be patented and the prior art are such that the subject matter as a whole 
would have been obvious at the time the invention was made to a person having ordinary 
skill in the art to which said subject matter pertains. Patentability shall not be negatived 
by the manner in which the invention was made. 

4. Claims 2-3, 14-15, 26, and 27 are rejected under 35 U.S.C. 103(a) as being unpatentable 

over Brendel (US Patent No. 6,772,333 Bl) in view of Tal et al (US Patent No. 6,625,612 Bl). 

Hereinafter, referred to as Brendel and Tal. 

With respect to claims 2-3, 14-15, 26 and 27, Brendel discloses searching for a server in a 

table according to SSL session ID (col. 9, lines 5-12). Brendel does not disclose obtaining 

address information from the data packet; searching a table using the address information for the 

session identity; using the address information in a hash function to obtain a hash value; and 

using the hash value to find the session identity. Tal discloses a method for obtaining the session 

identity from the address information. The table search operation begins with the translation of 

the search key, e.g., MAC address, IP address, TCP/IP session, into a (table) address by hash 

function HASH 1 (key) and into a signature by hash function HASH2(key). In some cases, the 

search results include session identifiers (col. 9, lines 36-47). It would have been obvious to one 

having ordinary skill in the art at the time the invention was made to include locating the session 
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identity by the address information in Brendel's system, as suggested by Tal, to identify existing 
connections therefore, packets can be routed efficiently. 

Allowable Subject Matter 

5. Claims 8, 11-12, 20, 23-24, 32, and 35-36 are objected to as being dependent upon a 
rejected base claim, but would be allowable if rewritten in independent form including all of the 
limitations of the base claim and any intervening claims. 

Response to Arguments 

6. Applicant's arguments with respect to claims 1-3, 6-15, 18-27, and 30-36 have been 
considered but are moot in view of the new ground(s) of rejection. 

Conclusion 

7. The prior art made of record and not relied upon is considered pertinent to applicant's 
disclosure. 

Hong et al (US Pub 2002/0062372 Al) discloses high performance server farm with 
tagging and pipelining. 

Doughs et al (US Pub 2002/0007415 Al) discloses method for content distribution in a 
network supporting a security protocol. 

Miller et al (US Pub 2005/0261985 Al) discloses load balancing technique implemented 
in a data network device utilizing a data cache. 

8. Any inquiry concerning this communication or earlier communications from the 
examiner should be directed to Anh-Vu H. Ly whose telephone number is 571-272-3175. The 
examiner can normally be reached on Monday-Friday 7:00am - 4:00pm. 



Application/Control Number: 09/852,433 



Page 15 



Art Unit: 2667 

If attempts to reach the examiner by telephone are unsuccessful, the examiner's 
supervisor, Chi Pham can be reached on 571-272-3179. The fax phone number for the 
organization where this application or proceeding is assigned is 571-273-8300. 

Information regarding the status of an application may be obtained from the Patent 
Application Information Retrieval (PAIR) system. Status information for published applications 
may be obtained from either Private PAIR or Public PAIR. Status information for unpublished 
applications is available through Private PAIR only. For more information about the PAIR 
system, see http://pair-direct.uspto.gov. Should you have questions on access to the Private PAIR 
system, contact the ElectronjcJBlosiness Center (EBC) at 866-217-9197 (toll-free). 
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